When compared to TextBox controls, these controls are really simple. Not only do they expose relatively few properties, they also support a limited number of events, and you don't usually write much code to manage them.
Using CommandButton controls is trivial. In most cases, you just draw the control on the form's surface, set its Caption property to a suitable string (adding an & character to associate a hot key with the control if you so choose), and you're finished, at least with user-interface issues. To make the button functional, you write code in its Click event procedure, as in this fragment:
Private Sub Command1_Click() ' Save data, then unload the current form. Call SaveDataToDisk Unload Me End Sub |
You can use two other properties at design time to modify the behavior of a CommandButton control. You can set the Default property to True if it's the default push button for the form (the button that receives a click when the user presses the Enter key—usually the OK or Save button). Similarly, you can set the Cancel property to True if you want to associate the button with the Escape key.
The only relevant CommandButton's run-time property is Value, which sets or returns the state of the control (True if pressed, False otherwise). Value is also the default property for this type of control. In most cases, you don't need to query this property because if you're inside a button's Click event you can be sure that the button is being activated. The Value property is useful only for programmatically clicking a button:
' This fires the button's Click event. Command1.Value = True |
The CommandButton control supports the usual set of keyboard and mouse events (KeyDown, KeyPress, KeyUp, MouseDown, MouseMove, MouseUp, but not the DblClick event) and also the GotFocus and LostFocus events, but you'll rarely have to write code in the corresponding event procedures.
CheckBox controls are useful when you want to offer your users a yes or no, true or false choice. Anytime you click on this control, it toggles between the yes state and the no state. This control can also be grayed when the state of the CheckBox is unavailable, but you must manage that state through code.
When you place a CheckBox control on a form, all you have to do, usually, is set its Caption property to a descriptive string. You might sometimes want to move the little check box to the right of its caption, which you do by setting the Alignment property to 1-Right Justify, but in most cases the default setting is OK. If you want to display the control in a checked state, you set its Value property to 1-Checked right in the Properties window, and you set a grayed state with 2-Grayed.
The only important event for CheckBox controls is the Click event, which fires when either the user or the code changes the state of the control. In many cases, you don't need to write code to handle this event. Instead, you just query the control's Value property when your code needs to process user choices. You usually write code in a CheckBox control's Click event when it affects the state of other controls. For example, if the user clears a check box, you might need to disable one or more controls on the form and reenable them when the user clicks on the check box again. This is how you usually do it (here I grouped all the relevant controls in one frame named Frame1):
Private Sub Check1_Click() Frame1.Enabled = (Check1.Value = vbChecked) End Sub |
Note that Value is the default property for CheckBox controls, so you can omit it in code. I suggest that you not do that, however, because it would reduce the readability of your code.
OptionButton controls are also known as radio buttons because of their shape. You always use OptionButton controls in a group of two or more because their purpose is to offer a number of mutually exclusive choices. Anytime you click on a button in the group, it switches to a selected state and all the other controls in the group become unselected.
Preliminary operations for an OptionButton control are similar to those already described for CheckBox controls. You set an OptionButton control's Caption property to a meaningful string, and if you want you can change its Alignment property to make the control right aligned. If the control is the one in its group that's in the selected state, you also set its Valueproperty to True. (The OptionButton's Value property is a Boolean value because only two states are possible.) Value is the default property for this control.
At run time, you typically query the control's Value property to learn which button in its group has been selected. Let's say you have three OptionButton controls, named optWeekly, optMonthly, and optYearly. You can test which one has been selected by the user as follows:
If optWeekly.Value Then ' User prefers weekly frequency. ElseIf optMonthly.Value Then ' User prefers monthly frequency. ElseIf optYearly.Value Then ' User prefers yearly frequency. End If |
Strictly speaking, you can avoid the test for the last OptionButton control in its group because all choices are supposed to be mutually exclusive. But the approach I just showed you increases the code's readability.
A group of OptionButton controls is often hosted in a Frame control. This is necessary when there are other groups of OptionButton controls on the form. As far as Visual Basic is concerned, all the OptionButton controls on a form's surface belong to the same group of mutually exclusive selections, even if the controls are placed at the opposite corners of the window. The only way to tell Visual Basic which controls belong to which group is by gathering them inside a Frame control. Actually, you can group your controls within any control that can work as a container—PictureBox, for example—but Frame controls are often the most reasonable choice.
CheckBox, OptionButton, and CommandButton controls have been with Visual Basic since version 1, and their basic set of properties have remained unchanged for years. Visual Basic 5, however, introduced a new, interesting graphic mode, which transforms these old-fashioned controls into more modern user-interface gadgets that are more likely to catch your users' attention, as you can see in Figure 3-5. Since the properties involved are exactly the same for all three controls, I'll describe them together.
Figure 3-5. CheckBox, OptionButton, and CommandButton controls come with a graphic flavor.
If you want to create a graphical control, you begin by setting its Style property to 1-Graphical; the appearance of the control changes, and a border is drawn around it. (This is more evident with CheckBox and OptionButton controls.) Then you choose a suitable image by clicking on the Picture property and navigating through your collection of icons and bitmaps. (You have a collection of icons and bitmaps, don't you?) In most cases, this is all you need to do to create graphical buttons. If you care about the details, you can select a second icon for the down state and assign it to the DownPicture property.You can also select a different icon for the disabled state and assign it to the DisabledPicture property. You can set these properties at run time, even though this is strictly necessary only when you create the user interface dynamically (for instance, a user-defined toolbar with his or her favorite commands):
Command1.Picture = LoadPicture("c:\vb6\myicon.ico") |
You might need to consider two additional properties when you're assigning images. The MaskColor property defines which color in the bitmap is to be considered the transparent color. Any pixels in the loaded picture that match this color won't be transferred; in their place, the regular button background color will be used. (The default value for this property is &HC0C0C0, light gray. The MaskColor property is active only if you also set the UseMaskColor to True, however—otherwise, it's ignored. These properties are useful only for bitmaps because icons (ICO files) and metafiles (WMF and EMF files) already include information about transparency. Note that you should always assign an RGB color to the MaskColor property (as opposed to a system color) because system colors depend on the end user's settings, and your button might not appear on other systems as it appears on yours.
Apart from the graphical look, CheckBox, OptionButton, and CommandButton controls using the Style=1-Graphical setting behave exactly like their textual counterparts. If you have a series of graphical radio buttons, only one of them stays down when pressed. When you press a graphical CheckBox control once, it goes into the down state, which is really the checked state. You press the button again to make it go in the up, or the clear, state. It's that simple.